I've seen this posted elsewhere but the proposed solutions don't apply to, or are simply 'solutions' we can't apply in this environment. We occasionaly see one or both of the following on desktops and laptops alike "Could not reconnect all network drives" balloon message and an icon in the system tray No balloon message but the icon exists in the system tray Understandably this happens off the network (although we want to suppress that), however, this happens while on the network. In every case that we've seen this, when we check 'Computer' (formerly 'My Computer'), all of the network drives are connected. Windows reports a 'false positive' - so to speak. Briefly here's our setup Win 7 Enterprise in a domain environemnt Built-in Win 7 firewall has been disabled; No third-party software firewall solutions present Network drives are mapped via net use /persistent:yes, Explorer with reconnect & logon set & via exporting/importing the network drive information from HKCU\Network We use a login script, however, the login script does not handle the mapping of all of our network drives. This is because we have a number of different departments, who, over the years, used overlapping drive letters and there are some situations where users also overlap departments that use overlapping drive letters. (This goes back before my time.) So instead, users map their own drives, remember the credentials and reconnect at logon. Furthermore, when users call the Help Desk, the Help Desk uses the '/persistent:yes' switch/parameter when doing mappinv via command line. Not sure if this is relevant, but, when we move users to a new machine, or reimage their machine, we backup & restore the HKCU\Network key, which houses the mapped connections, to make the transition nearly seamless. (So, doing a `net use * /delete /Y` to 'fix' this problem is not an option here.) Is there anything I can do to to prevent that message from popping up along with preventing the icon from displaying in the system tray? Although the "Always wait for the network at computer startup and logon" and "Turn off all balloon notifications" GPO settings are set to 'Enabled', those are the only potentially relevant GPO setting I could find, and they don't appear to fix this issue. Also, I've been looking at the setting discussed here http://support.microsoft.com/kb/937624/en-us but although users are promoted to local administrators via a GPO I'm not certain that applies here or if that will help. Lastly, thanks to another post I found on the forums, I ran across this setting http://support.microsoft.com/kb/297684 and am wondering if this is worth investigating, however, I'm concerned of how changing this setting may affect the servers the user's are connecting to based on way this sentence was phrased: "This behavior occurs because the systems can drop idle connections after a specified time-out period (by default, 15 minutes) to prevent wasting server resources on unused sessions. " If we set this value to some insanely high value (65535), how might that impact a server with a 1000 connections? Any suggestions are greatly appreciated.

Two things First: Bump! Second: While were on the subject of network drives, I wanted to share with everyone something else we've discovered. Steps taken to reproduce the problem. 1. Logon to a machine 2. Map some network drives and check the ‘reconnect at logon’ box. a. Or use net use with the /persistent flag 3. Create shortcuts that reference files on the network drive (like F:\my files\info.txt; h:\home_drive\application.exe) 4. Shutdown or Restart 5. Disconnect the network cable 6. Login to the machine 7. The network drives connection icon (and balloon notification) appears 8. Connect to the VPN network 9. Try to access the shortcuts created on the desktop (this fails). 10. Open a command window and type `net use` to confirm status of drives 11. Open the ‘Computer’ window (formerly ‘My Computer’; or open Explorer & go to Computer) 12. Double click the network drives 13. Go back to the shortcuts on the desktops and they now work. In Windows XP, if a user has a persistent network connection (a remembered network drive), when they logon, it immediately reconnects the drive. If the same user logs into the same Windows XP machine while offline (disconnected from the network) naturally the drives don't reconnect. They're in the same 'disconnected' state as in we've observed. If we take that same user and have them connect to our VPN system, within seconds of establishing a connection, Explorer re-connects the network drives without the user doing anything. This is nearly instant, not a 30-60 second thing, as once I connected to the VPN I opened Explorer and the drives were already connected. So, I don't expect there to be any real surprises at this point, but here's the interesting part... Windows 7 behaves differently. If you follow the same steps in Windows 7, Explorer will *not* re-connect the network drives; It doesn't automatically re-establish a connection to the network like Windows XP. We've tested this on a few Windows XP & Windows 7 machines and its 100% repeatable. Something specific must be triggered before Explorer [on Windows 7] re-connects the network drives. I won't go into great detail but I will say that UNC paths (\\server\share\file) work fine (be it a shortcut or start > run), while anything that references a drive letter (F:\file, G:\Folder) fails. (I'm curious, as anyone else noticed this?) The good news is that we opened a ticket with Microsoft and they were able to reproduce this problem and have confirmed it is a 'bug' but there's no word on whether or not this is seen as something that needs to be fixed. I mentioned the network drive bubble & icon issue but they were more focused on the network drive issue I discuss here. If you want more information on this, let me know if you want to know. I have a video that details this but I can't release it just yet without first cleaning it up.

I think I've found a workaround for this issue. If you disconnect the mapped drives from My Computer, log off and back on again (I have persistence enabled) it makes the reconnect error balloon stop popping up.

I think I've found a workaround for this issue. If you disconnect the mapped drives from My Computer, log off and back on again (I have persistence enabled) it makes the reconnect error balloon stop popping up.

Thanks for taking the time to read & reply to this thread. How do you disconnect the mapped drives: Right click disconnect? net use Drive: /delete /y? Some other method? As time permits I'll try to test this but I'm concerned abhout implementing this workaround programmatically across ~1500 machines. Here is another post discussing the same thing: http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/48f5ca04-6561-404d-b3ab-897320593aa6

Thanks for taking the time to read & reply to this thread. How do you disconnect the mapped drives: Right click disconnect? net use Drive: /delete /y? Some other method? As time permits I'll try to test this but I'm concerned abhout implementing this workaround programmatically across ~1500 machines. Here is another post discussing the same thing: http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/48f5ca04-6561-404d-b3ab-897320593aa6

Hi JuliusPIV.... I am curious if you have found out any further info on the re-connection of network drive's when connecting to the VPN. This has been a on-going issue for the company I work for....for the last few months. But now, we just rolled out 130 new windows 7 machines to be used primarily off-site. They have a batch file they run, that pulls info from a network drive. So naturally, the sales people are not going in and initiating the network drive first. And as you said, Windows XP did this on its own. Have you heard anything back from Microsoft for a fix to this bug? Or have you perhaps found a work around to the issue? I was going to begin working on a script to put in the VPN client that would connect this drive for them....but have not found the time. And if Microsoft has a hotfix or something in the works, that would be great to know. Any further info you could provide would be great. Thanks!!

It actually worked for right-click disconnect and net use Drive: /delete /y. It did randomly resurface once, but the reason for that was that Active Directory was mapping the user drive automatically at login, but the drive was being mapped in the login script as well. I removed it from the login script, and haven't seen it since. I started off implementing this on a few computers for testing purposes, and as of Monday have successfully rolled this out to the entire company (about 150 users). I have not had any user complaints, or seen the issue since.

Hi JuliusPIV.... I am curious if you have found out any further info on the re-connection of network drive's when connecting to the VPN. This has been a on-going issue for the company I work for....for the last few months. But now, we just rolled out 130 new windows 7 machines to be used primarily off-site. They have a batch file they run, that pulls info from a network drive. So naturally, the sales people are not going in and initiating the network drive first. And as you said, Windows XP did this on its own. Have you heard anything back from Microsoft for a fix to this bug? Or have you perhaps found a work around to the issue? I was going to begin working on a script to put in the VPN client that would connect this drive for them....but have not found the time. And if Microsoft has a hotfix or something in the works, that would be great to know. Any further info you could provide would be great. Thanks!!

It actually worked for right-click disconnect and net use Drive: /delete /y. It did randomly resurface once, but the reason for that was that Active Directory was mapping the user drive automatically at login, but the drive was being mapped in the login script as well. I removed it from the login script, and haven't seen it since. I started off implementing this on a few computers for testing purposes, and as of Monday have successfully rolled this out to the entire company (about 150 users). I have not had any user complaints, or seen the issue since.

Good point - as part of our migration process we backup existing mapped drives which also includes their home directory. We'll try to take that into consideration thanks for sharing this is great news.

Good point - as part of our migration process we backup existing mapped drives which also includes their home directory. We'll try to take that into consideration thanks for sharing this is great news.

Found this in another forum Whenever I mapped the drives in Windows it asked for credentials. However these credentials were then created with a persistence type of "Logon session" which is not editable. Having discovered this, I restarted windows and then before supplying the credentials to reconnect the mapped drives, I added credentials explicitly as follows: 1. Goto Control Panel -> All control Panel Items -> Credentials Manager 2. Next to the heading "Windows Credentials" click on the link "Add a Windows credential". 3. Enter the name of your server and the appropriate credentials. The result is an entry that has a persistence type of "Enterprise". This seems to do the trick. (I then restarted windows) This fixed the problem for me, hope it does for you. BTW. In order for windows to resolve the server name you may have to create an entry in the "Hosts" file located in "C:\Windows\System32\drivers\etc".

Found this in another forum Whenever I mapped the drives in Windows it asked for credentials. However these credentials were then created with a persistence type of "Logon session" which is not editable. Having discovered this, I restarted windows and then before supplying the credentials to reconnect the mapped drives, I added credentials explicitly as follows: 1. Goto Control Panel -> All control Panel Items -> Credentials Manager 2. Next to the heading "Windows Credentials" click on the link "Add a Windows credential". 3. Enter the name of your server and the appropriate credentials. The result is an entry that has a persistence type of "Enterprise". This seems to do the trick. (I then restarted windows) This fixed the problem for me, hope it does for you. BTW. In order for windows to resolve the server name you may have to create an entry in the "Hosts" file located in "C:\Windows\System32\drivers\etc".

From Microsoft after submitting the Design Change Request (DCR) and Business Impact Statement I was in Redmond last week and this issued was discussed in detail with the development team . We did figure that this is a change in the design /code that lead to the issue you are seeing . The team weighed the effort of investigating this further ; the effort of changing the component code that has already being isolated verses a workaround for the issue that could be provided. The team felt that this request did not meet the set ( high) bar for taking in design change request for Windows 7 . Case notes indicate there are some workarounds that have been work on by previous engineers who worked on this case with you. If not, the Dev team and me will be glad to work on the workaround by editing the scripts. With my request the Dev team will file this design change request for the next OS release (the one after Windows 7) . At this moment I don’t know if this request will be accepted in the next release but if will certainly be discussed and a decision will be made. Cause and Status There is a change in code path /design from windows XP to Windows 7 that is leading to this behavior A request of design change was filled . The team weighed the effort of investigating this further ; the effort of changing the component code that has already being isolated verses a workaround for the issue that could be provided. The team felt that this request did not meet the set ( high) bar for taking in design change request for Windows 7 . With my request the Dev team will file this design change request for the next OS release (the one after Windows 7) . At this moment I don’t know if this request will be accepted in the next release but if will certainly be discussed and a decision will be made. Workaround One of the basic script workarounds is that , if we have a batch script that will attempt to access \\server\share that should be mapped to z: then the expected behavior can be achieved with net use. At the top of the batch script we can add the line: net use z:\\server\share In the situation where we currently have a failed access, the script will work precisely the same. If the user was in a functional situation then the added line will give the following error message: “System error 85 has occurred. The local device is already in use.” However, the batch script will continue as before providing the expected functionality. If this error message is not acceptable (although it will be hard to notice it because if we just click on a script it will flash the cmd window by quickly) then the output can be suppressed. Using “net use z: \\server\share 2> nul” will suppress any errors this command would produce.

From Microsoft after submitting the Design Change Request (DCR) and Business Impact Statement I was in Redmond last week and this issued was discussed in detail with the development team . We did figure that this is a change in the design /code that lead to the issue you are seeing . The team weighed the effort of investigating this further ; the effort of changing the component code that has already being isolated verses a workaround for the issue that could be provided. The team felt that this request did not meet the set ( high) bar for taking in design change request for Windows 7 . Case notes indicate there are some workarounds that have been work on by previous engineers who worked on this case with you. If not, the Dev team and me will be glad to work on the workaround by editing the scripts. With my request the Dev team will file this design change request for the next OS release (the one after Windows 7) . At this moment I don’t know if this request will be accepted in the next release but if will certainly be discussed and a decision will be made. Cause and Status There is a change in code path /design from windows XP to Windows 7 that is leading to this behavior A request of design change was filled . The team weighed the effort of investigating this further ; the effort of changing the component code that has already being isolated verses a workaround for the issue that could be provided. The team felt that this request did not meet the set ( high) bar for taking in design change request for Windows 7 . With my request the Dev team will file this design change request for the next OS release (the one after Windows 7) . At this moment I don’t know if this request will be accepted in the next release but if will certainly be discussed and a decision will be made. Workaround One of the basic script workarounds is that , if we have a batch script that will attempt to access \\server\share that should be mapped to z: then the expected behavior can be achieved with net use. At the top of the batch script we can add the line: net use z:\\server\share In the situation where we currently have a failed access, the script will work precisely the same. If the user was in a functional situation then the added line will give the following error message: “System error 85 has occurred. The local device is already in use.” However, the batch script will continue as before providing the expected functionality. If this error message is not acceptable (although it will be hard to notice it because if we just click on a script it will flash the cmd window by quickly) then the output can be suppressed. Using “net use z: \\server\share 2> nul” will suppress any errors this command would produce.

Am I right to discern from MSs reply to you that they are suggesting that: in the situation where a user is connecting to VPN (after windows logon) to run a batch script manually in order to reestablish connection with their mapped network drives?

Am I right to discern from MSs reply to you that they are suggesting that: in the situation where a user is connecting to VPN (after windows logon) to run a batch script manually in order to reestablish connection with their mapped network drives?

Hey Mikes87: That sounds about right. Very specific actions trigger the network refresh by Explorer, but is it worth the hassle of trying to explain that process to a user? Even worse is how silly that looks on paper! For instance, if I had a shortcut pointed to a mapped drive (Like Z:\path\something\file.exe) and I right clicked on the shortcut, I think that triggered a refresh and suddenly all mapped drives worked. From what I think I remember, batch scripts can trigger a refresh of the network connections but a VBScript will not. If I can help, let me know. Its been ages since I last messed with this!

Had the same issue here with a T420S on Win 7 Enterprise 64-bit but was traced to a SD card in the laptops slot. Once that was removed, an F5 refreshed the 7 missing network drives in My Computer.

Had the same issue here with a T420S on Win 7 Enterprise 64-bit but was traced to a SD card in the laptops slot. Once that was removed, an F5 refreshed the 7 missing network drives in My Computer.

Had this issue on a Vista machine and a W2K8 Terminal Server. Found that the users had a previous persistent drive mapping to their Personal User Drive (U: drive). Since then, their personal user drive mapping (U: drive) was added to their AD profile for automatic mapping. Resolved by disconnecting their personal user drive at the problem machine by right clicking and selecting disconnect. This kills the persistent mapping. After reboot, the AD profile takes over and maps the drive (U: drive). Error no longer appears. Hope this helps...

Had this issue on a Vista machine and a W2K8 Terminal Server. Found that the users had a previous persistent drive mapping to their Personal User Drive (U: drive). Since then, their personal user drive mapping (U: drive) was added to their AD profile for automatic mapping. Resolved by disconnecting their personal user drive at the problem machine by right clicking and selecting disconnect. This kills the persistent mapping. After reboot, the AD profile takes over and maps the drive (U: drive). Error no longer appears. Hope this helps...